REMARKS 

The above amendment and these remarks are responsive to 
the Office action of Examiner Sean M. Reilly of 30 Jun 2 005, 
designated final . 

Claims 1-106 are in the case, none as yet allowed. 

Priori ty 

Applicants have amended the specification to provide 
the current status of the parent application. 

35 U.S.C. 101 

Claims 71-106 have been rejected under 35 U.S.C. 101 as 
directed to non-statutory subject matter. 

Applicants have amended the specification and claims 
105 and 106, without prejudice, so as to remove the 
reference to fluid transmission medium from the 
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specification and to clarify that the program instructions 
are recorded on a tangible storage medium. 

Applicants urge that claims 71-106 be determined to be 
drawn to statutory subject matter under 35 U.S.C. 101. 

35 U.S.C. 112 

Claims 58-62 have been rejected under 3 5 U.S.C. 112, 
second paragraph, as being indefinite. 

Applicants have amended claim 58, and thereby claims 
59-62 which depend therefrom, so as to provide the 
appropriate antecedent basis. 



35 U.S.C. 102 

Claims 1, 3-12, 17-20, 22-32, 34-43, 48-58, 60-63, 65- 
71, 73-82, 87-88, 90-99, and 104-106 have been rejected 
under 35 U.S.C. 102(e) over Boe et al . 6,122,276 (Boe 
hereafter) . 
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In his Response to Arguments, the Examiner states: 

"...the following factual arguments are noted: a. Boe 
failed to teach a confirmation record and other various 
server responses reaching a client. Additionally Boe 
failed to disclose the client and server communicating 
using a same communication protocol. ..." 

"In considering (a) , Examiner respectfully disagrees 
with Applicant' s argument. Applicant contents (sic, 
contends) that 1) Boe fails to send a confirmation 
record to a client and also contends that 2) the client 
and server of Boe's system fail to communicate using a 
same communication protocol. With regard to point #1, 
Boe clearly teaches in figure 4, line E transmitting a 
confirmation record to the TN3270 server. It is noted 
that Applicant explicitly states this fact on pg 35 of 
Applicant's response dated 2/25/05 and page 36 of 
Applicant's response dated 8/31/05. Examiner has 
equated Applicant's claimed client with Boe's TN 3270 
server. Within Boe's system, the TN3270 server (Figure 
1, 18) is itself a client of the host mainframe. 
Therefore Boe clearly teaches a client (TN3270 server) 
receiving a confirmation record. Further with regard 
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to point #2, the TN3270 and host mainframe of Boe's 
system communicate using the same protocol (i.e. the 
proprietary SNA protocol) (Boe Col 2, lines 1-5) . 
Applicant's arguments as to which protocol is utilized 
for communication between the TN3270 server and TN3270 
client of Boe's system is completely irrelevant since 
Examiner has equated Applicant's claimed client with 
Boe's TN3270 server. Additionally any of Applicant's 
arguments as to whether the TN32 70 server is or is not 
a telnet client are moot since none of the independent 
claims recite the word telnet, [Office Action, pages 
11-12, emphasis in original.] 

"Applicant also contends that other various server 
responses fail to reach the client. Again since the 
TN3270 server of figure 1, component 18 is itself a 
client within the Boe system then, by Applicant's own 
admissions in the response dated 2/25/05, Boe teaches 
all the limitations of Applicant's claimed invention." 
[Office Action, page 12.] 

The Examiner then kindly suggests that the definition 
of "client" be limited, otherwise the broadest reasonable 
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definition of a 'client' will be utilized by the Examiner. 
[Office Action, page 12.] 



Responsive to the Examiner's suggestion, applicants 
have amended the independent claims to recite that the 
client includes " a graphical user interface selectively 
assigned a session name enabling client emulator 
communication at an application layer with said server " [See 
claim 1, for example.] Support for this clarification of 
the meaning of 'client' is found in applicant's 
specification at page 10, line 8 to page 11, line 12. 

Applicants are aware that in their broadest claims they 
do not specifically recite "telnet". Rather, these claims 
are directed to a client and a server communicating over a 
connection using a same client/server communications 
protocol and, by this amendment, further to emulator and GUI 
described above . 

In distinguishing Boe, however, since Boe specifically 
teaches Telnet and SNA communications protocols, in order to 
discuss the fair teachings of Boe it is necessary to refer 
to Telnet and SNA and show how Boe's references to Telnet 
and SNA communications do not support the Examiner's 
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application of Boe to applicants claims. 

The Examiner states that Boe Figure 1 shows TN3270 
server 18 is a Telnet client. Applicant's traverse. Server 
18 cannot be a Telnet client, as Boe describes the 
connection from TN3270 server 18 to host mainframe 12 as 
"SNA communications" (Col. 2, lines 1-5). Telnet clients 
and servers use the same communications protocol (usually 
TCP/IP communications, as SNA is a proprietary 
communications protocol) . Boe Figure 1 requires that line 
16 be a TCP/IP connection (Col 1, lines 35-40) and line 20 
as an SNA connection (Col. 2, lines 1-5) . 

Now, Boe exploits the SNA communications Figure 1, line 
20, to implement his ACTLU x "confirmation record" in Figure 
4, line E. Thus, it would be correct to say that TN3270 
server 18 is an SNA client of host mainframe 12, but it 
would not be correct to say server 18 is Telnet client of 
mainframe 12. Responses from host mainframe 12 to TN3270 
server 18 (in particular, the ACTLU x in Figure 4, line E) 
are SNA responses which are not passed back to a real Telnet 
client, but to an SNA client. In fact, what Boe's patent 
really shows is TN3270 server 18 acting as a gateway (TCP- 
to-SNA protocol converter) between Telnet client 14 and host 
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mainframe 12. Applicant's invention requires no such 
converter, and as such has advantages of Boe in that 
responses are returned to actual clients (as defined in the 
amended claims) and can result in additional processing at 
the client (to support new or enhanced functions) . 

The independent claims were previously amended to more 
clearly state that a client is a device which communicates 
over the client /server connection using the same 
communication protocol as the server. Unlike Boe, such 
communication requires no converter (TN3270 server 18 is, as 
previously noted, such a converter, and not a true client as 
now defined). In applicant's claimed system, unlike Boe, 
responses are returned to actual clients and can result in 
additional processing at client (such as the TN3270 client 
14 of Boe, for example) to support new or enhanced 
functions . 

Further, with the above understanding, Applicants argue 
that Boe still is distinguished from applicants invention, 
as stated in the previous amendment, in that Boe has an 
additional level of indirection not found in applicants 
claims, as well as for the above described distinction that 
communications between Boe's client (TN3270 14) and server 
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(host 12) are not in the same communications protocol. 

Specifically, Boe has a TN3270 client (Fig. 1, element 
13) , a TN 3270 server (Fig. 1, element 18) and also a legacy 
Host (Fig. 1, element 12) . This means that Boe has 
communication between the TN3270 client and the TN3270 
server (as do applicants) , but he also has communication 
between the TN3270 server and the legacy Host (also like 
applicants, but applicants claims are not directed to this 
level of communication.) 

This distinction is important, for the negotiations and 
communications of interest in Boe occur between the TN3270 
server 18 and the legacy Host 12. Applicants have no 
comparable level of communication, for all negotiations and 
communications of interest in applicants' claims occur 
between applicants client (such as a TN5250 client) and 
server (such as a TN5250 server) . 

Specifically, the confirmation record payload 
represented by applicants' claimed invention (Figure 2, 
block 122) gets returned by applicants (TN5250) server (Fig. 
3, server 42) to applicants (TN5250) client (Fig. 3, client 
40) . 
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Thus, when applicants describe passing back information 
in a confirmation record to applicants' client, this 
information is actually communicated to the TN5250 client 
(Fig. 3, client 40). In Boe's case, this information is 
communicated from the legacy Host to the TN3270 server, and 
it does not continue on to an actual TN3270 client . 

The significance of this distinction is that the TN3270 
client of Boe is not actually involved in any of the 
negotiations specified in applicants' claims. In other 
words, the actual TN3270 client is not able to act on any 
information from the "confirmation record", such that it 
could, for example, do retry processing using a different 
set of negotiation variables, or taking corrective actions 
based upon the error code returned in the confirmation 
record. As suggested by the Examiner, applicants have 
amended the claims to clarify that the * client' they claim 
cannot be read on TN3270 server 18. 

The goal of Boe is to enable the legacy Host to track 
clients (Col. 7, lines 8-12) by processing in the TN3270 
server (called the "communications gateway" in his claims) , 
Applicants invention is distinct in that it seeks to enable 
programmable negotiations by the client. 
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Turning now to applicants' claim 1 and the teachings of 
Boe, Figure 4, as applied by the Examiner (starting at page 
4 of the Office Action), consider the following analysis: 



1. Method for processing a client session request, 
comprising the steps of: 

The Examiner says Figure 1 of Boe shows TN3270 
server 18 to be a Telnet client. Applicants 
traverse. This cannot be a Telnet client, as the 
patent describes this connection from TN3270 
server 18 to Host Mainframe 12 as W SNA 
communications" (Col. 2, lines 1-5). 

negotiating environment parameters for establishing a 
connection-oriented connection with said client, said 
client and said server communicating over said 
connection using a same client/server communications 
protocol , said client including a graphical user 
interface selectively assigned a session name enabling 
client emulator communication at an application layer 
with said server ; 
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and servers that they use the same communication 
protocol (usually TCP/IP communications, inasmuch 
as SNA is a proprietary communications protocol.) 
Boe Fig. 1 requires line 16 to be a TCPIP 
connection (Col. 1, lines 35-40) and line 20 to be 
an SNA connection (Col. 2, lines 1-5). These are 
not the same communication protocol. By the 
limitation added to the claim (underlined) , the 
* client' includes a client emulator having a GUI 
selectively assigned a session name, and cannot 
therefore be read on the TN3270 server 18 of Boe. 

inviting said client to submit user variables; 

Examiner: line C, which is from TN3270 server to 
Host . 

Boe here introduces the additional level of 
indirection referred to previously, and from now 
on communications are between TN3270 Server and 
Host, and not between the TN3270 Server and TN3270 
Client . 
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responsive to receiving a user variable requesting a 
custom confirmation record, sending to said client a 
confirmation record and custom record data. 

Examiner: lines D and E, Fig. 4. 

Applicants traverse on this critical point. The 
custom record data (line E) is not returned to the 
client as asserted by the Examiner, but rather to 
the TN32 70 server. Thus, in Boe, the confirmation 
record and custom record data are not returned to 
the TN3270 Client, as is required by applicants' 
claims . 

Boe exploits the SNA communications (Fig. 1, line 
20) to implement his ACTLU x "confirmation record" 
in Fig. 4, line E. Thus, it would be correct to 
say that TN3270 Server 18 is an SNA client of Host 
mainframe 12, but it would not be correct to say 
server 18 is a Telnet client of mainframe 12. 
Responses from Host Mainframe 12 to TN3270 Server 
18 (in particular, the ACTLU x in Fig. 4, line E) 
are SNA responses which are not passed back to a 
real Telnet client, but to an SNA client. In 
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fact, what Boe's patent really shows is TN3270 
Server 18 acting as a gateway (TCP-to-SNA protocol 
converter) between Telnet client 14 and Host 
Mainframe 12 . 

With respect to claim 18, the Examiner rejects for 
reasons similar to those presented for claim 1. Applicants 
traverse . 

Boe does show a client and server, but no client/server 
connection as now set forth in the claims. There is no 
teaching of the exit program communicating information back 
to a client (as that is now defined in the claims) using a 
same client/server communication protocol. Boe Figure 4 
shows responses flowing from the host 12 to the server 18, 
but no such flow on to the client 14. Thus, Boe does not 
enable the client 14 to act on any response from the host or 
the server. 

With respect to claim 3, applicants traverse the 
Examiner's characterization and application of Boe. 
Applicants claim3 is similar to Boe in that normal TCP/IP 
connection establishment occurs. However, the negotiation 
for the confirmation record response does not occur here, 
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for Boe (Col. 3, line 25) refers to line C in Figure 3. 
Instead, this request for confirmation record occurs in Boe 
in Fig. 4, lines C and D, which do not correspond to line C 
in Figure 3. Line H in Fig. 3 does show a response, but 
this not a confirmation record response. It is possible the 
Examiner intended to cite Line E in Fig. 4 as the 
confirmation record response (ACTLU x) , but as is clear from 
the figure, this response goes to the TN3270 server, and not 
to the TN3270 client. 

With respect to claims 4-6, applicants traverse the 
Examiner's rejection. As previously argued, the responses 
cited by the Examiner are fed to the TN3270 server and, most 
importantly, not to the TN3270 client. Applicants agree 
that Boe has his version of a confirmation record, but argue 
that Boe does not teach that the confirmation record is 
accessible to the intended client. 

With respect to claims 7-8, applicants traverse. As 
stated before, the Boe responses go to the TN3270 server and 
not to the TN3270 client. 

With respect to claims 9-12, and 17, applicants 
traverse. As stated before, the Boe responses go to the 
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TN3270 server and not to the TN3270 client. 

With respect to claims 19, 20 and 22, which have been 
rejected for reasons similar as for claims 1-8 and 18, 
applicants again traverse. Again, Boe is using his TN3270 
server as the "client" in his architecture. The fact that 
the server is performing the actions described gives no 
advantage as set forth in applicants claims to the TN3270 
client that connects to the TN3270 server. 

With respect to claims 23, 32, 49, 58, 63, 71, 88, 105, 
and 106, all other independent claims in the case, 
applicants traverse the Examiner's characterization of Boe's 
teachings, which are asserted by the Examiner for similar 
reasons as for claim 1, and respond thereto as above for 
claim 1. 

With respect to claims 34, 60, 65, 73, and 90, 
applicants traverse the Examiner's characterization and 
application of Boe. Applicants claims 2 and 3 are similar 
to Boe in that normal TCP/IP connection establishment 
occurs. However, the negotiation for the confirmation 
record response does not occur here, for Boe (Col. 3, line 
25) refers to line C in Figure 3. Instead, this request for 
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confirmation record occurs in Boe in Fig. 4, lines C and D, 
which do not correspond to line C in Figure 3. Line H in 
Fig. 3 does show a response, but this not a confirmation 
record response. It is possible the Examiner intended to 
cite Line E in Fig. 4 as the confirmation record response 
(ACTLU x) , but as is clear from the figure, this response 
goes to the TN3270 server, and not to the TN3270 client. 

With respect to claims 35-37, 61-62, 66-68, 74-76, 91- 
93, applicants traverse and argue, as asserted with respect 
to claims 4-6, that the responses cited by the Examiner are 
fed to the TN3270 server and, most importantly, not to the 
TN3270 client. Applicants agree that Boe has his version of 
a confirmation record, but argue that Boe does not teach 
that the confirmation record is accessible to the intended 
client . 

With respect to claims 38-39, 69-70, 77-78, and 94-95, 
applicants traverse and argue, as with respect to claims 7- 
8, that the Boe responses go to the TN3270 server and not to 
the TN3270 client. 

With respect to claims 40-43, 48, 79-82, 87, 96-99, and 
104, applicants traverse and argue, as with respect to 
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* * 



claims 9-12 and 17, that the Boe responses go to the TN32 70 
server and not to the TN3270 client. 

Applicants have amended all of the independent claims 
1, 18, 23, 32, 49, 58, 63, 71, 88, 105, and 106 to further 
clarify the operation of the client and server, and to 
define the client as a device which communicates with the 
server using a same client/server communication protocol, 
the client including a graphical user interface selectively 
assigned a session name enabling client emulator 
communication at an application layer with said server, and 
urge that the rejection of these claims over Boe be 
reconsidered and withdrawn, and these claims allowed. 



35 U.S.C. 103 

Claims 1-12, 17-20, 22-43, 48-82, 87-99, and 104-106 
have been rejected under 35 U.S.C. 103(a) over Boe et al, 
6,122,2 76 (Boe hereafter) and Chen et al . (U.S. Patent 
6,182,220, hereinafter Chen), and claims 13-16, 21, 44-47, 
83-86, and 100-103 have been rejected under 35 U.S.C. 103(a) 
over Boe and Murphy et al . (RVD 287, u 5250 Telnet 
Enhancements" July 2000; hereinafter Murphy) . 
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Applicants traverse the rejection of these dependent 
claims the reasons stated above with respect to their 
respective base claims in which applicants have shown that 
the Boe reference, when applied to base claims as currently 
amended, does not teach the client/server system as 
characterized by the Examiner. 

The Examiner notes that Chen does not teach responsive 
to receiving a user variable requesting a custom 
confirmation record received at the server from the client, 
with the server sending to the client a confirmation record 
and custom record data for enabling the client to engage in 
subsequent programmable negotiations directly with the 
server. [See Office Action, page 7.] However, for this 
teaching the Examiner refers to Boe, referring to host 12 as 
the server and TN3270 server 18 as the client. As 
previously explained, these components of Boe do not meet 
the requirements of the amended claims. 

Similarly with respect to Murphy, the Examiner 
references Boe TN3270 as the client and host 12 as the 
server in addressing the requirements of the base claims, 
and cannot, therefore, now properly assert that the clients 
are TN3270 client 14, 30 for the purpose of reading Boe on 
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the dependent claims. As previously explained, as the 
amended claims now clarify, the base claims cannot be read 
on the host 12 and server 18. 

Applicants urge that claims 1-106 be allowed. 



SUMMARY AND CONCLUSION 

Applicants urge that the above amendments be entered 
and the case passed to issue with claims 1-106. 

The Application is believed to be in condition for 
allowance and such action by the Examiner is urged. Should 
differences remain, however, which do not place one/more of 
the remaining claims in condition for allowance, the 
Examiner is requested to phone the undersigned at the number 
provided below for the purpose of providing constructive 
assistance and suggestions in accordance with M.P.E.P. 
Sections 707.02 (j) and 707.03 in order that allowable claims 
can be presented, thereby placing the Application in 

END920010020US1 53 of 54 S/N 09/932,615 



4 



condition for allowance without further proceedings being 
necessary. 



Date: 13 Apr 2006 

Shelley M Beckstrand, P.C. 
Patent Attorney 
61 Glenmont Road 
Woodlawn, VA 24381-1341 

Phone: (276) 238-1972 

Fax: (276) 238-1545 
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Sincerely, 



R. G. Hartmann, et al . 



By 




